Defining the right granularity for your ProDataSets
A ProDataSet can represent one or more tables (and any external data structure that can be mapped to it). Often, of course, a single object or document in your application has a complex structure that requires multiple levels of master-detail relationships. This is what the multiple tables of a ProDataSet can be used for.
What then is the right size for your ProDataSets?
There is no single right answer to this question, but if you think of your ProDataSets as representing business objects or documents your application manages, then you should be able to define the right scope for them. Even with such a simplified database as the Progress Sports2000 database that we have been using to illustrate the use of the ProDataSet, you can identify some combinations of tables that can properly be thought of as single business objects and some that probably can’t.
For example, an Order is a common object in many applications. Generally, an Order has a header record. This is likely the right choice for the top level of an Order ProDataSet. The OrderLines for an Order can then be a separate table in the same ProDataSet, if you think of the OrderLines as being a part of the Order.
Are the Item records then also a part of the Order? Well, probably not, even though we have added an Item temp-table to the Order ProDataSet in these examples so that we can demonstrate certain things about how ProDataSets work. The Item identifier is a part of each OrderLine, but the Item list or catalog itself is really independent of any particular Order. You might decide that having a separate temp-table in an Order ProDataSet that lets you pull in Item detail information for all the Items used in a particular Order is a useful way to represent the data, as we have done in some of these examples. This is perfectly legitimate if it suits your purposes, but that is different from how you think of the Item catalog as a whole.
In this situation, ProDataSets let you define multiple levels of granularity and then combine them as you need to. For example, you can define an Item temp-table ttItem and an Item ProDataSet dsItem to represent Items as objects in their own right. You could use this ProDataSet to present a list of all Items or all Items that satisfy some selection. Having a ProDataSet that contains just one table is perfectly reasonable. Even though there are no relations within the ProDataSet, the ProDataSet structure still provides services for you to manage the Items. For example, it could provide a common internal definition for the ttItem table and perhaps common FILL logic to map the external Items onto the internal temp-table, as shown in Figure 9–1.
In Figure 9–1, itemSource.p represents a procedure that manages the Data-Source and FILL logic for the ttItem table. This is the kind of procedure we’ll use to build a simple example later in this section.
You could then use this same ttItem temp-table and any of its logic as part of a larger ProDataSet, such as an Order ProDataSet that wants to present Items used in the Order, as shown in Figure 9–2.
Note that while you can’t actually make a ProDataSet such as dsItem a part of another ProDataSet, you can make its temp-tables part of another ProDataSet such as dsOrder by using a different buffer for the temp-table. Because the SET-CALLBACK-PROCEDURE mechanism lets you associate event procedures in any running procedure with a ProDataSet event, you can combine logic from multiple support procedures in a single ProDataSet.